Yêu cầu là gì? Các bài báo nghiên cứu khoa học liên quan
Yêu cầu là mô tả có thể kiểm chứng về chức năng, hành vi hoặc đặc tính của hệ thống, sản phẩm hoặc dịch vụ nhằm đáp ứng nhu cầu và mục tiêu của các bên liên quan. Yêu cầu là cơ sở để thiết kế, phát triển, kiểm thử và quản lý thay đổi trong suốt vòng đời dự án, bảo đảm tính khả thi, hiệu quả và minh bạch.
Định nghĩa “Yêu cầu”
Yêu cầu (requirement) là mô tả chi tiết về chức năng, hành vi hoặc đặc tính của hệ thống, sản phẩm hoặc dịch vụ mà các bên liên quan mong đợi hoặc cần đạt được. Mỗi yêu cầu phải rõ ràng, có thể kiểm chứng và gắn liền với mục tiêu kinh doanh hoặc kỹ thuật cụ thể để đảm bảo tính khả thi và hiệu quả.
Yêu cầu có thể xuất phát từ nhiều nguồn: khách hàng, người dùng cuối, quy định pháp luật, tiêu chuẩn ngành hoặc giới hạn công nghệ. Việc xác định đầy đủ và chính xác các yêu cầu ban đầu là cơ sở để thiết kế, phát triển và kiểm thử thành công sản phẩm.
Một yêu cầu tốt cần đáp ứng các tiêu chí SMART: Specific (cụ thể), Measurable (đo lường được), Achievable (có thể đạt được), Relevant (liên quan) và Time-bound (có thời hạn). Việc tuân thủ các tiêu chí này giúp giảm thiểu hiểu nhầm và thay đổi sau này.
Phân loại yêu cầu
Yêu cầu chức năng (Functional Requirement) mô tả các chức năng mà hệ thống phải thực hiện, thường được định nghĩa qua các use case hoặc user story. Ví dụ: “Hệ thống cho phép người dùng đăng nhập bằng mã OTP gửi qua email.”
Yêu cầu phi chức năng (Non-Functional Requirement) tập trung vào các đặc tính chất lượng như hiệu năng, bảo mật, khả năng mở rộng, khả năng sử dụng và độ tin cậy. Ví dụ: “Thời gian phản hồi trang web không vượt quá 2 giây khi truy cập đồng thời 1.000 người dùng.”
Yêu cầu nghiệp vụ (Business Requirement) phản ánh mục tiêu kinh doanh cao nhất, thể hiện giá trị và lợi ích khi dự án hoàn thành. Ví dụ: “Tăng tỷ lệ chuyển đổi khách hàng mới thêm 15% trong vòng 6 tháng.”
Yêu cầu kỹ thuật (Technical Requirement) liên quan đến hạ tầng, công nghệ và tiêu chuẩn phát triển. Ví dụ: “Hệ thống phải sử dụng OAuth2 cho xác thực và tuân thủ tiêu chuẩn OWASP Top 10.”
Quy trình thu thập yêu cầu
Xác định bên liên quan (Stakeholder Analysis): liệt kê và phân loại các nhóm đối tượng có nhu cầu hoặc chịu ảnh hưởng bởi dự án (khách hàng, người dùng, quản lý, nhóm vận hành). Sử dụng ma trận power-interest để ưu tiên phỏng vấn và tương tác.
- High Power, High Interest: Chủ động tham vấn thường xuyên.
- High Power, Low Interest: Cập nhật định kỳ.
- Low Power, High Interest: Mời tham gia workshop.
Phỏng vấn và workshop: tổ chức buổi làm việc nhóm tập trung (JAD session) và phỏng vấn cá nhân để thu thập yêu cầu chi tiết, kịch bản sử dụng, và các điều kiện bất thường.
Quan sát hiện trường (Observation) và khảo sát (Survey): ghi nhận quy trình thực tế, thu thập dữ liệu định lượng về tần suất, lỗi phát sinh để bổ sung yêu cầu liên quan đến hiệu suất hoặc tính ổn định.
Prototype và mô hình hóa (Prototyping & Modeling): xây dựng mẫu giao diện nhanh (wireframe) hoặc mô hình luồng nghiệp vụ (process flow) để rà soát và hiệu chỉnh yêu cầu trực quan trước khi phát triển chi tiết.
Tiêu chuẩn và công cụ
ISO/IEC/IEEE 29148:2018 – Chuẩn quốc tế về Kỹ thuật yêu cầu (Systems and software engineering — Life cycle processes — Requirements engineering) quy định quy trình thu thập, phân tích, xác thực và quản lý yêu cầu.
BABOK® Guide (A Guide to the Business Analysis Body of Knowledge) do IIBA xuất bản cung cấp khung phân tích nghiệp vụ, bao gồm kỹ thuật elicitation, phân tích và quản lý yêu cầu.
- Jira: quản lý backlog, user story, workflow phê duyệt yêu cầu.
- IBM DOORS: theo dõi traceability và quản lý yêu cầu phức tạp.
- Azure DevOps: tích hợp quản lý yêu cầu, mã nguồn và CI/CD.
Các công cụ modeling (UML, BPMN) hỗ trợ vẽ sơ đồ use case, luồng dữ liệu (DFD) và sơ đồ thực thể – quan hệ (ERD) giúp mô tả yêu cầu chức năng và dữ liệu.
Viết và mô tả yêu cầu
Mỗi yêu cầu cần được mô tả rõ ràng, đầy đủ và nhất quán, đảm bảo mọi bên liên quan có thể hiểu và kiểm chứng. Định dạng yêu cầu thường bao gồm ID duy nhất, tiêu đề ngắn gọn, mô tả chi tiết, điều kiện tiền đề (preconditions), bước thực hiện (steps) và tiêu chí chấp nhận (acceptance criteria).
Ví dụ định dạng user story:
As a [role], I want [feature] so that [benefit]. Trong đó:
- role: người dùng hoặc hệ thống tương tác
- feature: hành vi mong muốn
- benefit: giá trị kinh doanh
Yêu cầu phi chức năng có thể mô tả theo dạng:
The system shall [quality attribute] such that [quantifiable measure]. Ví dụ: “The system shall handle 5,000 concurrent users with response time under 2 seconds.”
Xác minh và xác thực yêu cầu
Xác minh (verification) đảm bảo yêu cầu được viết đúng theo tiêu chuẩn và không mâu thuẫn, thường thực hiện qua peer review, walkthrough hoặc inspections. Phương pháp này kiểm tra tính hoàn chỉnh, độ rõ ràng và tính khả thi của từng yêu cầu so với tiêu chuẩn ISO/IEC/IEEE 29148 https://www.iso.org/standard/72011.html.
Xác thực (validation) đảm bảo giải pháp triển khai đáp ứng nhu cầu thực tế của bên liên quan, thực hiện qua việc thiết kế test case dựa trên acceptance criteria và thực thi kiểm thử chức năng, kiểm thử hiệu năng hoặc kiểm thử người dùng (UAT).
Hoạt động | Mục tiêu | Công cụ |
---|---|---|
Peer Review | Phát hiện lỗi mô tả | Checklist, review meeting |
Walkthrough | Đồng thuận hiểu biết chung | Wireframe, prototype |
Test Case Design | Đảm bảo tính khả thi | JUnit, Selenium |
Quản lý sự thay đổi
Quy trình kiểm soát thay đổi yêu cầu (Change Control) gồm đề xuất thay đổi, đánh giá tác động (impact analysis), phê duyệt và theo dõi. Hội đồng kiểm soát thay đổi (Change Control Board - CCB) gồm đại diện kỹ thuật, kinh doanh và quản lý nhằm đảm bảo mọi thay đổi được cân nhắc toàn diện.
Các bước chính:
- Ghi nhận yêu cầu thay đổi (RFC)
- Phân tích tác động: chi phí, lịch trình, rủi ro
- Phê duyệt hoặc từ chối bởi CCB
- Cập nhật tài liệu yêu cầu và traceability matrix
- Thông báo tới các bên liên quan và điều chỉnh kế hoạch
Theo dõi và truy xuất nguồn gốc
Traceability matrix liên kết yêu cầu với thiết kế, mã nguồn và các ca kiểm thử, đảm bảo tính toàn vẹn và khả năng theo dõi suốt vòng đời. Ma trận thường có dạng bảng:
Requirement ID | Thiết kế (Design Doc) | Module Code | Test Case ID |
---|---|---|---|
REQ-001 | DD-Login-01 | AuthService.java | TC-Login-01 |
REQ-002 | DD-Profile-05 | UserProfile.js | TC-Profile-03 |
Theo dõi tự động qua các công cụ ALM như Jira, Azure DevOps, giúp báo cáo trực quan tiến độ, độ bao phủ kiểm thử và trạng thái phê duyệt.
Thách thức và kinh nghiệm
Thiếu rõ ràng dẫn đến scope creep khi phát triển những tính năng ngoài phạm vi ban đầu; khắc phục bằng việc duy trì backlog, ưu tiên theo MoSCoW (Must, Should, Could, Won’t).
Mâu thuẫn yêu cầu giữa các bên liên quan: cần tổ chức workshop để thương lượng ưu tiên và xác lập ràng buộc rõ ràng trước khi phê duyệt.
Khó đo lường yêu cầu phi chức năng: đề xuất thiết lập chỉ số đo lường (KPI) cụ thể như thời gian phản hồi, khả năng chịu tải và tỉ lệ lỗi, kiểm thử định kỳ để đảm bảo tuân thủ.
Tài liệu tham khảo
Các bài báo, nghiên cứu, công bố khoa học về chủ đề yêu cầu:
Mục tiêu. Kiểm tra tính giá trị cấu trúc của phiên bản rút gọn của thang đánh giá trầm cảm, lo âu và căng thẳng (DASS-21), đặc biệt đánh giá xem căng thẳng theo chỉ số này có đồng nghĩa với tính cảm xúc tiêu cực (NA) hay không hay nó đại diện cho một cấu trúc liên quan nhưng khác biệt. Cung cấp dữ liệu chuẩn hóa cho dân số trưởng thành nói chung.
Thiết kế. Phân tích cắt ngang, tương quan và phân ...
...- 1
- 2
- 3
- 4
- 5
- 6
- 10